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REMARKS 

Applicant thanks Examiner for the detailed review of the application. Examiner currently 
rejects applicant's claims 1, 5-6, 10-11, 15-16, 19, 23, 25-26, 28-34, and 36-38 under 35 U.S,C 
103(a) as being unpatentable over Clark et al (US 5,187,780), herein referred to as Clark, in view of 
Zimmerman ("OSI Reference Model")* 

Applicant's claim 1 includes the following limitations, "a type field to specify a transaction 
type. . .wherein the format field and the type field together indicate a packet type," (emphasis 
added). As disclosed in applicant's claim 1 the transaction type is selected from a group consisting 
of a memory request, an input/output request, a configuration request and a message request. In 
addition, embodiments of packet types are illustrated in applicant's description in Table 2. Claim 5 
further includes examples of packet types including a memory read request, a memory write request, 
an input/output (IO) read request, an 10 write request, a configuration read, a configuration write, a 
message request, a message request with data, a message for advanced switching, a completion 
without data, a completion with data, and a completion for lock memory read. 

In contrast, Clark discloses the following: 

The header and information portion 22 of the packet 
20 of FIG. 2 includes a type or command field 24 speci- 
fying what type of message is being transmitted, fol- 
lowed by a length field 25 specifying the length of the 
message expressed as the number of bytes. An address 

As can be seen, Clark only disclose the use of length field 25 and type or command field 24 

separately to define the message, such as the type of message and the length of the whole message. 

However, applicant's claim 1 differs in many respects from this disclosure. First, the format field 

provides a size of the packet header, not the whole message, Le. message packet 20. Second, the 

type field in applicant's claim 1 is to specify a transaction type and a combination of the format field 

and the type field to specify a packet type, as described above. Clark does not disclose or suggest 
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use of any fields to indicate two type', such as a basic transaction type and a specific packet type, but 
only a single message type from single type field 24. 

Applicant's claim 6 includes the limitation, "an additional field to hold additional 
information, wherein the format field and the type field together specify a type of additional 
information to be held in the additional field," (emphasis added). In contrast Clark only discloses 
the following; 

be from zero to 4089 bytes in length. An acknowledge 
packet h of the same format as the packet 20 of FIG. 2, 
but it has a zero-length data field 29, and it has no length 
field 23; the type field 24 of an acknowledge packet has 
a certain code for a positive acknowledge and another 
code for a negative acknowledge or NAK, 

A$ can be seen, Clark only suggests that the type field itself as a code for a positive acknowledge 

and another code for a negative acknowledge, but does not disclose another field including a 

different type of information based on a format and a type field. The header of applicant's claim 6 

includes a type of additional information based on the format field and the type field. 

Embodiments described in the description are illustrated in Figures 4-8, For example, in a request 

packet last double word enable information and first double word enable information are included in 

an additional field. However, for a message the additional field includes message code information, 

and for a completion the additional field includes completion status information* Clark does not 

describe, disclose, or suggest different types of information in any additional field, such as field 26- 

28, based on other fields of the header, as in applicant's claim 6. 

Referring next to applicant's claim 1 1, the following element is included, "the transaction 

layer to determine a type of additional information in the additional field based on the format field 

and the type field together." Similar to the discussion immediately above, Clark also does not 

disclose determining a type of information in an additional field of a header based on other fields of 

Attorney Docket M2P13764 1 1 Application Number: 10/040,605 

PAGE 15/17 * RCVD AT 4/26/2007 6:16:06 PM [Eastern Daylight TimeJ * SVR:USPTO-EFXRF-2/4 * DNIS:2738300 * CSID:5033561415 * DURATION (mm-ss):05-02 



Fax: 5033561415 



fipr 26 2007 15:26 P. 16 



the header. As disclosed in applicant's embodiments, which are discussed above, a field of the 
header is set to hold different information, such as enable information, completion information, or 
message information based on the packet type specified by the format and type fields. However, 
Clark does not disclose or suggest the use of fields 24-28 in any similar manner. 

Applicant has added new independent claim 39, which includes, "a first field to indicate a 
size of the packet header and to indicate whether the packet is to include a data payload, . .a third 
field to represent a length of the data payload, in response to the first field indicating the packet 
is to include a data payload/* As illustrated above in the excerpt from Clark, only a single 
length/size field, i.e. size field 25 is disclosed. In contrast, applicant's claim 39 includes two 
length/size fields; a first field to indicate a size of the packet header and a third field to represent a 
length of the data payload, while Clark only describes length field 25 in the header specifying the 
length of the overall message. 

As Zimmerman only discusses the 7 layers of networking protocol and there is no discussion 
of packet headers or fields, applicant respectfully submits that Zimmerman also does not disclose 
the aforementioned elements/limitations. Therefore, applicant respectfully submits that independent 
claims 1, 6, U , and 39, as well as their dependent claims, are now in condition for allowance for at 
least the reasons stated above. 
// 
// 
// 
// 
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If there are any additional charges, please charge Deposit Account No. 50-0221. If a 
telephone interview would in any way expedite the prosecution of the present application, the 
Examiner is invited to contact David P. McAbee at (503) 712-4988. 



Intel Corporation 
M/S JF3-147 
21 11NE 25 th Avenue 
Hillsboro, OR 97124 
Tele -503-712-4988 
Fax -503-264-1729 



Respectfully submitted, 
Intel Corporation 



Dated: April 26, 2007 



/David P. McAbee/Ree. No. 58.104/ 
David P. McAbee 
Reg. No. 58,104 
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